-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Custom getCallerClass in entitlement bridge #125139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
For me it fixes the debugger connection problem. Don't understand it enough to approve but at least it seems to works in my case. |
libs/entitlement/bridge/src/main/java/org/elasticsearch/entitlement/bridge/Util.java
Show resolved
Hide resolved
Pinging @elastic/es-core-infra (Team:Core/Infra) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you expand the PR description? Without that it's very difficult what this PR does and why.
Sorry @ldematte! Forgot to update the description when I moved this out of Draft. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I suppose a test for the empty walk case isn't really possible?
See ES-11273
Problem
StackWalker.getCallerClass
is specified to throwIllegalCallerException
when it is "called from a method which is the last frame on the stack". It turns out this includes situations where a method is called via JNI from a native method. @smalyshev observed that, when attaching a debugger usingserver=y
, a native method callsThread.isDaemon
, and our instrumentation inside the latter callsgetCallerClass
which throws.Rejected solutions
The most obvious remedy would be to write a wrapper method that calls
getCallerClass
and catches the exception; however, this would add an extra stack frame that would causegetCallerClass
to return the wrong frame.Inserting a catch into the instrumentation bytecode is a possibility, but it would dramatically increase the complexity of the instrumentation, which is currently quite straightforward.
Selected solution
I've opted to implement our own
getCallerClass
with the behviour we want, as a drop-in replacement for the one fromStackWalker
. Instead of throwing when there's no caller frame, it returns a marker classNO_CLASS
to indicate that condition.